心理的にも手順的にも負担を減らした現担当チームのMTGスタイルについて書いてみた

現在担当のチームで週に1度行っているMTGについて、SmartMeetingの機能と実際の職務プロセスとを併せみながら、無理に機能を使おうとはせず且つこれまでの有用か疑問だった慣習を止めつつ、必要なチェックや議論は担保している状況について書いてみました。

haoyayoi

2021.04.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

MTGといえば、某カードゲームを思い出す方多数おられるかもしれません。私が最後に触ったエキスパンションはExodusでした。

それはさておき、私が所属しているAWS事業本部サービスGのバックエンドシステム担当チームでも例外なくMTGは週に1度あります。ただし、営業日数が少ない週や、連休等で出社しているメンバーが少なければスキップします。その分は翌週に回されるわけですね。

MTGには、特に何も無い場合にもとにかく確保した時間を司会が頑張って時間を潰すとか、そんな風にネガティブなイメージが過去の職場ではありました。クラスメソッド全体に言えるのかはわかりませんが、少なくとも現在のチームでは1時間程確保した上でも10分で終わることもよくあります。何もないなら各自の課題解決に時間を使いたい、ということです。なお、現担当チームと書いてますが、入社以来同じチームです。

実際にどんな感じでMTGを行っているのか、振り返りながら書いてみました。

SmartMeetingでの通知

基本はSmartMeetingのbotから通知されるスケジュールをたどり、議事録ページを開きます。以前の議事録はConfluenceベースでしたが、現在はSmartMeetingベースに移行しています。

気をつける点としては、スケジュールの都合で時間帯が変更になった場合にSmartMeeting側が十二分に追従してくれるかどうかはわからないというところ。その場合はSmartMeeingのスケジュール一覧で本来の時間帯に予定されていた議事録ページを利用します。

Meetingの開始

司会担当の場合はSmartMeetingの議事録ページを開きます。

3分前くらいにGoogle Meetで該当のMeetingを開き、参加する直前の画面で背景等を調整し、1分あるいはちょうどのタイミングで参加します。現在は皆慣れているのか音声のハウリングが一切発生していません。全員が参加したことを確認して、司会が画面を全画面共有にします。参加が遅れているメンバーがいたら、Slack上でmentionを掛けておきます。

あとは、議事録のアジェンダに沿って進めていきます。Backlogのチケット、及びGitHubのIssueとPull-Requestで直近7日内に更新があったものに絞りつつ、更新した事を振り返ります。Pull-Requestについては必要に応じてコードレビューを含めて、Mergeできるものについてはその場でMergeまで済ませていきます。

特に追加確認することがなければ30分程度で、早ければ10分で完了です。

気になるSmartMeetingの議事録ページ上の内容は以下の内容をベースに、連絡事項が各自からあれば告げて、司会がそれを記載しています。チケットやIssueについて何かあれば、該当のチケット及びIssueに直接書くためにこのボリュームなのですが、チーム外の人が見ると書かれていることが少なすぎるからか大体驚かれます。

Meeting内容で行ったシュリンク

以前はチケットやIssueを議事録上への転記など、惰性でやっていた手続きもありました。

が、「既に存在するチケット・Issueの内容が議事録に分散するのもなんだかな」という思いから、転記せずに確認済みサイン用のチェックボックスだけにしました。

サービスG全体MTGでの報告についても、前回から更新されたチケットやIssueから一覧化したものをベースにしつつチームMTG議事録やSlackで共有されたことを加え、サマリから一歩踏み込んだ報告が必要と感じたら各自で申告するスタイルです。議事録へ転記した内容をサービスG全体MTGでの報告にも用いていましたが、チームMTGとサービスG全体MTGの間で更新による差異が頻繁にあり、手直しに手間とられるくらいならと割り切りました。

また、MTG中に課題が発生した場合はなるべくGitHub Issueから即起こすようにしており、現在の議事録は手続きを終えた確認記録とも言える状態です。